A publish/subscribe system is an effective way of disseminating information from “publishers” to multiple users or “subscribers.” A publisher generates messages, also referred to as events, which contain a topic and some data content. A subscriber, also referred to herein as a “client,” provides, ahead of time, a criterion, also referred to as a subscription, that specifies the information, based on published messages, that the system is required to deliver to that subscriber client in the future. In a publish/subscribe system, publishers and subscribers are anonymous in that publishers do not necessarily know the number of subscribers or their locations; and subscribers do not necessarily know the locations of the publishers.
In the publish/subscribe system, subscribers typically receive only a subset of the total messages published. The messages may be selected for reception and processing using topic-based or content-based filtering. In a topic-based system, messages are published to “topics” or named logical channels. Subscribers in a topic-based system will receive all messages published to the topics to which they subscribe, and all subscribers to a topic will receive the same message. The publisher is responsible for defining the classes of messages to which subscribers can subscribe. The messages may be filtered using the subscription criterion which can be tested on each message independent of any other message. For example, a filtered published message might be “topic=Detroit Tigers & winning” for all messages related to the topic of the Detroit Tigers baseball team winning.
In a content-based system, messages are only delivered to a subscriber if the attributes or content of those messages match the constraints (subscription criterion) defined by the subscriber. The subscriber is responsible for classifying the messages.
In many publish/subscribe systems, publishers post messages to an intermediary message broker and subscribers register subscriptions with that broker, letting the broker perform the filtering.
Subscriber clients, including mobile computing clients, may use what are referred to as “macro components” in connection with the publish/subscribe system. A macro component is a bundle of components in a self-contained single object. Macro components in the context of a publish/subscribe system may be used to express events of interest to the message broker, provide the implementation to act upon those events of interest as well as provide the user interface components to convey the information of the event to the end user.
In certain computing environments, such as a mobile computing environment, it may be desirable to defer loading these macro components until the object is needed (referred to as “lazy loading”) to increase the efficiency in the program's operation. However, the event of interest may be published prior to the corresponding macro component being loaded.
As a result, in order for the macro component to receive the event data, the event data may be re-propagated (i.e., the event is republished) after the macro component has been loaded. However, the republication of the event results in the other subscribers receiving the event again thereby causing confusion and repetition.
Alternatively, the broadcast of the event may be delayed until the macro component is loaded. However, by delaying the broadcast of the event, other subscribers will receive the event data at a later point in time.
Neither of these solutions are effective in providing the event data to lazily-loaded macro components without adversely affecting the other subscribers.